Ryzen 7 9700X i Ryzen 5 9600X - premiera i oficjalne ceny, ZEN 5 nie zachwyca

1. a wystarzyło (autor: Shark20 | data: 9/08/24 | godz.: 00:41)
   powiedzieć odrazu prawdę. AMD powinno zapowiedzieć w czerwcu, że nowe procesory przyniosą około 12-15% więcej wydajności jednowątkowej, i około 5% więcej wydajności wielowątkowej, przy niższym zużyciu energii.
   
   
2. @news (autor: Promilus | data: 9/08/24 | godz.: 06:10)
   ciekawe czy czasem nie przystopowali po problemach intela i to jest skutek ;) Może jakiś spec uznał "nieee, nie możemy tak szarżować z agresywnymi zegarami i tdp bo wpadniemy w to samo g*wno co niebiescy" więc uznano, że jak nie wydajność to przynajmniej niech to jest chłodne i oszczędne. Taki Zen 4.1 ;)
   
   
3. @Promilus - o tym samym pomyślałem (autor: Qjanusz | data: 9/08/24 | godz.: 13:22)
   AMD najwidoczniej odważyło się zboczyć ze ścieżki absurdu. No i jest to jakieś zagranie Intelowi na nosie, na zasadzie, tam toczą się ludzkie dramaty, ścieżki się utleniają, krzem palony jest żywcem przez wyśrubowane limity napięcia, kompy i serwery zaliczają restarty, czasami nie wstają... tymczasem od Ryzena niemalże wieje chłodem i stabilnością.
   
   generalnie procki są ok, ale początkowa wycena jest zdecydowanie zbyt wysoka w stosunku do oferowanej wydajności. Z drugiej strony wiadomo że AMD ukryło w tej cenie zapas na obniżki po kontrze Intela. Więc kupno teraz ZEN5 wydaje się całkowicie pozbawione sensu. Czekamy na obniżki.
   
   Co do przeciętnego wzrostu wydajności ZEN5, to wydaje mi się że bardzo niskie TDP w połączeniu z odblokowanym mnożnikiem, daje już spore pole do popisu dla OC, gdzie z jednej strony procek trochę zapłonie, ale wydajność powinna być odpowiednio wyższa
   
   
4. oz procki sa slabe jesli chodzi o wydajnosc (autor: pawel1207 | data: 9/08/24 | godz.: 22:33)
   oraz drogie w stosunku do tego co sie dostaje... zaczyna sie golenie jeleni .. jedyny plus to to nizsze tdp ktre nie jest znowu az tak niskie jak te cpu sie rozkreca ogulnie ja sie zgadzam z gamers nexus..... te procesory sa takie sobie i nic wiecej zupelna przecietnosc przypomina to intelowe wyczyny kiedy zdominowal rynek :D a ktos kto ma poprzednia generacje moze o nich zupelnie zapomniec bo nie sa warte uwagi jescze gdyby kosztowaly tyle co poprzedniki spoko jest upgrade przynajmniej w tdp ale w sytuacji gdzie walneli za nie 25 % wiecej a wydajnosc w praktyce jest niewiele wieksza to wyglada jak skok na kase jak u inteliny podczas ich najlepszych dni :D
   
   
5. pojawiły się informacje (autor: Shark20 | data: 9/08/24 | godz.: 22:42)
   że z tych dwóch 4-drożnych dekoderów włączony jest tylko jeden, a drugi jest na off. Bo coś nie było ok gdy obydwa pracowały. To by tłumaczyło względnie niski wzrost IPC w ZEN 5. Bo rdzeń rozbudowano znacznie.
   
   Trzeba czekać na ZEN 6, czyli poprawioną wersję tej całkiem nowej architektury. Może jeden 6-drożny dekoder dadzą i będzie lepiej, plus wyższe taktowania wynikające z litografii N3P
   
   
6. test (autor: Shark20 | data: 9/08/24 | godz.: 22:48)
   https://www.computerbase.de/...p_und_kernverbrauch
   
   Ryzen 7 9700X 65/88W - taktowanie wielowątkowe około 4,5 GHz
   Ryzen 7 7700X 105/142 - taktowanie wielowątkowe około 5,3 GHz
   
   Tutaj jest tzw. pies pogrzebany.
   
   
   
   
   
7. @03 (autor: rzymo | data: 11/08/24 | godz.: 08:04)
   To nie to, że AMD się odważyło zboczyć ze ścieżki podbijania TDP - co sprzedaje procesory? Gry, wiele różnych dużych kanałów na YT testuje głównie w grach, soft 'użytkowy' jest dodatkiem.
   Podniesiesz TDP do ~100 W i jaki przyrost wydajności dostajesz? W Cinebenchu spory, ale ;) W grach wzrosty są symboliczne, a proc ciągnie np. 50 watów więcej...
   Z tego powodu w pełni rozumiem decyzję AMD. Przy okazji mogą się chwalić b. dobrym perf/W.
   
   
8. @rzymo (autor: Promilus | data: 11/08/24 | godz.: 09:30)
   Problem w tym, że o ile "unlocked" daje jakiś wzrost wydajności ze sporym narzutem energetycznym o tyle da się rozsądniej gospodarować energia i zbliżyć się do mocy maksymalnej. Kwestia tego, że zbyt agresywne napięcia skutkują grzaniem i dławieniem wydajności (zbijaniem taktowania boost). Ale względem wartości fabrycznych można znaleźć ustawienia, które są ... no, powiedzmy "bardziej optymalne" do gier. I jeśli jest jakiś zarzut dla AMD to taki, że fabryczne są zbyt "łagodne". No chyba, że jednak - jak napisałem w 2 komentarzu - AMD zrobiło jakieś badania statystyczne i endurance na próbkach produkcyjnych i wyszło im, że to są optymalne ustawienia ze względu na wydajność ORAZ stabilność i żywotność.
   
   
9. Te mityczne przyrosty mocy to jest ile? (autor: etranger | data: 12/08/24 | godz.: 07:55)
   10 klatek? Czyli z 300 na 310 jeśli chodzi o gry dla chłopców co ganiają po kolorowanym przez zjaranego grafika świecie?
   Moim zdaniem to wyszlo im całkiem przyzwoicie, podobna wydajność a spadek poboru mocy znaczny.
   Ja musze mocno grzebać w biosie zeby mój 14700 nie utlenił się za tydzień czy dwa a i tak potrafi połknąć sporo ponad dwieście watt.
   Owszem w CB mam wynik fajowy ale przecież nie bede cale godziny wlaczal sobie CB.
   
   
   
   
   
   
10. @Shark20 (autor: PCCPU | data: 12/08/24 | godz.: 18:55)
    Testy samej mikroarchitektury pokazują, że pojedynczy wątek w Zen5 działa podobnie jak Zen4, czyli dekodowanie x86 4-Way, a dopiero SMT aktywuje drugi klaster dekodera (w sumie 8-Way). Niestety jest to sprzeczne z tym, co powiedział Mike Clark w wywiadzie dla C&C i prawdopodobnie oba klastry dekodujące nie działają tak jak w Gracemont czy Skymont w trybie ST.
    
    Cóż, wygląda na to, że AMD po raz kolejny ma problemy z rozbudową rdzenia. Mieli to po raz pierwszy w erze K10. Teraz znów mają problem i nie zdziwcie się, jeśli w przyszłości pojawi się Zen z pojedynczym dekoderem 8-drożnym lub podwójnym 6-drożnym.
    
    
    
    
11. PCCPU (autor: Markizy | data: 12/08/24 | godz.: 19:51)
    w przypadku k10 nie próbowali dokładać następne dekodery, zdjęcia które przedstawiały niby 4 dekodery były fakiem.
    
    W przypadku zen5 ulepszenia poszły na rzeczy mniej przydatne typowemu użytkownikowi.
    cinemabench sigle gdzie obydwa dobijają taki sam zegar
    9700x 135
    7700x 120
    
    Test w wordzie
    9700x 9810
    7700x 9098
    
    Zegary dla jednego wątka różnią się tylko o 100MHz, co przy taktowaniu 5,4GHz do 5,5GHz dake niecałe 2%. Ale różnice w pierwszy teście masz na poziomie 12,5%, w drugim 7,8% wiec nadal więcej niż samo taktowanie.
    
    Teraz przez najbliższe pare miesięcy będą poprawki przez mikrokod może dojdzie z 1-2% w singlu i kilka % więcej w multi. A w kolejnej generacji będą poprawiać słabości obecnej.
    Na tle 7700 pobór energii i wzrost wydajności nie zachwyca, ale na jego tle 7700x energetycznie też słabo wyglądał.
    
    
12. @Markizy (autor: PCCPU | data: 12/08/24 | godz.: 20:31)
    Zobacz zdjęcia struktury K10 i masz 4 komórki/struktury dekodera zamiast 3 jak w K8.
    
    Ale nie dokładnie to miałem na myśli. Chodziło mi raczej o to, że w epoce K10 Bulldozer został zaprojektowany z 4-kierunkowym „modułem” dekodera (rdzeniem) i jak na ironię dawał dwa małe, prostsze bloki typu Integer zamiast jednego dużego. Co ciekawe, tylko dwa bloki Integer w wielowątkowości są w stanie optymalnie wykorzystać 4-kierunkowy dekoder w Bulldozerze.
    AMD w pełni udało się wdrożyć dekoder 4-drożny tylko w Zen.
    
    
13. Edit (autor: PCCPU | data: 12/08/24 | godz.: 20:34)
    Zobacz zdjęcia struktury K10 i masz 4 komórki/struktury dekodera zamiast 3 jak w K8.
    
    Ale nie dokładnie to miałem na myśli. Chodziło mi raczej o to, że w epoce K10, Bulldozer był projektowany z 4-kierunkowym dekoderem w „module”(rdzeniu) i jak na ironię AMD dawało dwa małe, prostsze bloki typu Integer zamiast jednego dużego. Co ciekawe, tylko dwa bloki Integer w wielowątkowości są w stanie optymalnie wykorzystać 4-kierunkowy dekoder w Bulldozerze.
    AMD w pełni udało się wdrożyć dekoder 4-drożny dopiero w Zen.
    
    
14. @CD (autor: PCCPU | data: 12/08/24 | godz.: 20:44)
    Jest jeszcze jeden interesujący szczegół. Półtora roku temu David Suggs, który był głównym inżynierem Zen2 i Zen5, odszedł z AMD. Co ciekawe, Suggs najwyraźniej ma upodobanie do dużych jednostek FP.
    
    
    
    
15. @CD2 (autor: PCCPU | data: 12/08/24 | godz.: 21:09)
    Jeśli dalej myślisz że w K10(Phenom) dekoder 4-Way to fejk to już Ci udowadniam że fizycznie tam jest.
    
    Popatrz gdzie znadują się dekodery w K8(Athlon64)
    http://www.chip-architect.org/...n_Instr_Cache.jpg
    
    http://chip-architect.com/...AMDsy_64bit_Core.html
    
    A tutaj zdjęcie struktury rdzenia K10(Phenom):
    https://i.redd.it/h3gdn9rk2pdz.png
    
    
    
    
16. @PCCPU (autor: Promilus | data: 12/08/24 | godz.: 22:19)
    K10 miał 3 drożny dekoder. 4 drożny miał dopiero Bulldozer, ale tam z kolei były słabe klastry integer (Phenom miał 3 ALU/AGU na wątek z 3 drożnym dekoderem, Buldek miał 2ALU + 2AGU na wątek z 4 drożnym dekoderem. Zen5 ma 6ALU + 4AGU, do tego szersze i mocniejsze FPU. I potrafi te potoki wykarmić dzięki podwójnemi dekoderowi o ile tylko są 2 wątki. Ogółem diabeł tkwi w szczegółach i Zen5 pokazuje pazur z AVX512 i wielowątkowymi appkami.
    
    
17. @Promilus (autor: PCCPU | data: 12/08/24 | godz.: 22:30)
    K10 ma fizycznie 4-Way dekoder. Inna kwestia że krązyły plotki że był tylko eksperymentalnie do wewnętrznych testów AMD.
    
    Jeśli pojedynczy wątek nie jest w stanie spożytkować 2x 4-Wide dekoder to wiadomo że SMT zrobi z tego większy pożytek.
    
    
18. @CD (autor: PCCPU | data: 12/08/24 | godz.: 22:40)
    Mike Clark sam przyznaje w wywiadzie że na ten czas tylko 2x 4-Way dekoder x86 był w stanie umożliwić im poszerzenie rdzzenia i rezygnację z technik które były obecne w Zen4. Co więcej nie wykluczają w kolejnych generacjach powrót do pojedynczego ale szerszego dekodera i technik znanych z Zen4. Także mówi to samo za siebie. Na obecny czas nie są w stanie zaprojektować znacznie bardziej skomplikowany pojedynczy dekoder 8-Way.
    
    LionCove ma pojedynczy dekoder 8-Way. Zobaczymy które podejście jest lepsze.
    
    
19. @PCCPU (autor: Promilus | data: 13/08/24 | godz.: 05:24)
    Plotki to właśnie jest ten 4 way decoder w K10, plotki rozsiewane przez zawiedzionych fanów, którzy próbowali sobie tłumaczyć dlaczego to nie jest takie dobre jak miało być. I powstał taki urban legend o kagańcu na dekoderze. A prawda jest taka, że struktura jednostek wykonawczych w żaden sposób nie skorzystałaby z 4 drożnego dekodera bo jest 3 drożna!
    
    
20. ... Dlatego 8-way dekoder intela jest bez HT... (autor: SebaSTS | data: 13/08/24 | godz.: 17:44)
    ... Bo tak jest z tego wiekszy zysk IPC a mniejsze nakłady pracy przy projektowaniu i tranzystorów mniej. Jak ogarną w przyszłości dla HT to i AMD będzie miało bardziej dopracowany dekoder.
    
    
21. @SebaSTS (autor: PCCPU | data: 13/08/24 | godz.: 19:27)
    Wariant LionCove z dekoderem 8-Way dla Xeon ma mieć HT.
    
    
22. EDIT (autor: PCCPU | data: 13/08/24 | godz.: 19:33)
    Mniejsze nakłady przy projektowaniu to jest w podejściu AMD przy Zen5. Podwójny dekoder jest łatwieszy w projekcie i mniej skomplikowany zwłaszacza że łatwiej sporzytkować takie rozwiązanie przy SMT. Intela podejście z pojedynczym szerokim dekoderem jest bardziej skomplikowane i wymaga większej ilości tranzystorów. Inżynierowie Gracemont i Skymont twierdzą że klastrowe dekodowanie jest tańsze w projekcie i ilości użytych tranzystorów. Niestety Zen5 działa gorzej niż Gracemont/Skymont w pojedynczym wątku.
    
    
23. Najważniejsze jest i tak Perf/W i to jak będzie wypadać w serwerach (autor: pwil2 | data: 13/08/24 | godz.: 22:52)
    Tam najlepsze marże, ogromne zamówienia czekają. Wypełnią największe DataCenter i będzie pora na obniżki cen oraz dokładanie 3D cache.
    
    
24. c.d. (autor: pwil2 | data: 13/08/24 | godz.: 22:55)
    Póki co większości graczy wystarczą promocje na 5700X3D i 7800X3D oraz nowe 5500X3D
    
    
25. @ up, dekodery w ZEN 5 (autor: Shark20 | data: 14/08/24 | godz.: 00:16)
    jeden 4-drożny, który działa tylko gdy obsługiwany jest jeden wątek na rdzeniu
    drugi 4-drożny, który uaktywnia się dla potrzeb SMT (drugiego wątku).
    
    Moim zdaniem - nie tędy droga. Czyżby w AMD zapomnieli już lekcji otrzymanej z Bulldozera? To znaczy tego, że dzielenie zasobów rdzenia na sztywno pomiędzy dwa wątki prowadzi do znacznych ograniczeń wydajności w określonych sytuacjach (jak na drodze ruch wahadłowy?)
    
    Lepiej żey całe zasoby architektury wewnętrznej były dostępne dla każdego z dwóch wątków.
    
    Zamiast dwóch 4-drożnych dekoderów lepszy jest jeden 6-drożny dekoder, który działa zawsze, ponieważ
    - zapewnia wyższą wydajność jednowątkową
    - zapewnia podobna wydajność wielowątkowa w trybie SMT
    - na pewno zajmuje nie więcej tranzystorów niż dwa osobne 4-drożne dekodery wraz z dwoma osobnymi pamięciami L0 ("Op-cache").
    
    
    
    
26. @Promilus (autor: PCCPU | data: 14/08/24 | godz.: 18:58)
    "Plotki to właśnie jest ten 4 way decoder w K10, plotki rozsiewane przez zawiedzionych fanów, którzy próbowali sobie tłumaczyć dlaczego to nie jest takie dobre jak miało być. I powstał taki urban legend o kagańcu na dekoderze. A prawda jest taka, że struktura jednostek wykonawczych w żaden sposób nie skorzystałaby z 4 drożnego dekodera bo jest 3 drożna!"
    
    Conroe(Core 2) z 4 drożnym dekoderem ma 2x FP-ALU + 1x ALU + 2xAGU.
    
    
    
27. @CD (autor: PCCPU | data: 14/08/24 | godz.: 20:49)
    Diagram K10(Phenom):
    https://upload.wikimedia.org/...D_K10_Arch.svg.png
    
    Diagram Condor(Core 2):
    https://lh5.googleusercontent.com/...kHgTvwJWSrRdw
    
    Jak widać Conroe wcale nie ma więcej ALU ponieważ obie konstrukcje dysponują 3 portami z ALU. O ile AMD w K10 ma 3ALU, 3AGU i 3 porty FP o tyle Intel ma w Conroe ma 2FP-ALU, 1ALU, 1SD i 2AGU.
    
    
    
28. @PPCPU (autor: Promilus | data: 15/08/24 | godz.: 08:29)
    Conroe ma 1 complex decoder (produkujący 1-4 uops, ogarniający w pojedynkę wszystkie bardziej skomplikowane rozkazy x86) i 3 simple dekodery produkujące 1uops każdy. AMD miało już wtedy i ma do dziś symetryczne dekodery dające 1-2 macro ops. Czyli każdy kawałek tego dekodera ogarniał każdy rozkaz x86. I w przypadku K8, i K10 jak dobrze pamiętam potoki wykonawcze też były symetryczne (1ALU + 1AGU). Co chcesz udowodnić porównując jabłka i pomarańcze? Wszyscy specjaliści AMD listowali konkretne zmiany między K8 a K10. Były modyfikacje cache, była reorganizacja magistrali, były nowe rozkazy SSE, była szerokość FPU, były optymalizacje branch prediction, prefetch, fetch. Była głębokość potoku. O dekoderach nie było najmniejszej wzmianki. Ale uparcie twierdzisz - nie mając jakichkolwiek racjonalnych przesłanek - że były kurła 4.
    
    
29. @25. (autor: pwil2 | data: 15/08/24 | godz.: 22:47)
    Ciekawe, czy to takie metody oszczędzania energii i przy dwóch wątkach aktywuje się drugi dekoder i wspólnie pracują nad tym co dostają na wejściu, czy są całkiem niezależne. W pierwszym wypadku może się okazać, że profil zasilania Performance, albo inna sztuczka aktywuje oba na stałe.
    
    
30. Widzieliście testy pod Linuksem na Phoronix? (autor: pwil2 | data: 15/08/24 | godz.: 23:02)
    "When taking the geometric mean of those nearly 400 raw benchmark results, it sums up the greatness of Zen 5 with the Ryzen 5 9600X and Ryzen 7 9700X processors. The Ryzen 7 9700X delivered 1.195x the performance of the Core i5 14600K competition or 1.15x the performance of the prior generation Ryzen 7 7700X. The Ryzen 5 9600X came in at 1.35x the performance of the Core i5 14500 and 1.25x the performance of the Ryzen 5 7600X. Or if still on Zen 3 for comparison, the Ryzen 5 9600X was 1.82x the performance of the Ryzen 5 5600X."
    
    
31. c.d. (autor: pwil2 | data: 15/08/24 | godz.: 23:03)
    "The raw performance of these Ryzen 9000 series processors was extremely impressive. These new Zen 5 desktop processors showed significant uplift in areas such as gaming and single-threaded workloads commonly led by Intel like Python, NumPy, Cryptsetup, audio encoding, and web browser performance. The Zen 5 generational uplift also showed great strides in even better AVX-512 performance for helping more AI workloads to a lot of other strong finishes in technical computing and HPC workloads. Whether you are just a heavy web browser user and running lots of Python scripts to doing a lot of creator workloads and software development, Zen 5 is an exceptionally well rounded design. The performance of the Ryzen 9 9900 series and upcoming EPYC Turin server processors should be a real treat given what we are seeing out of these Zen 5 6-core and 8-core desktop parts."
    
    
32. c.d. (autor: pwil2 | data: 15/08/24 | godz.: 23:03)
    "The raw performance results alone were impressive for this big Linux desktop CPU comparison but it's all the more mesmerizing when accounting for the CPU power use. On average across the nearly 400 benchmarks the Ryzen 5 9600X and Ryzen 7 9700X were consuming 73 Watts on average and a peak of 101~103 Watts. The Ryzen 5 7600X meanwhile had a 92 Watt average and a 149 Watt peak while the Ryzen 7 7700X had a 99 Watt average and 140 Watt peak. The Core i5 14600K with being a power hungry Raptor Lake had a 127 Watt average and a 236 Watt peak. The power efficiency of these Zen 5 processors are phenomenal!"
    
    
33. c.d. (autor: pwil2 | data: 15/08/24 | godz.: 23:05)
    "Can one also say that no Intel 13/14th Gen CPUs were injured in the making of this test report?" ;-)
    
    
34. @Promilus (autor: PCCPU | data: 16/08/24 | godz.: 19:21)
    No to masz możliwości K10 z dekodera 3-Way 6 uops a możliwości Conroe z dekodera 4-Way 7 uops.
    
    Jabłka i pomarańcze? Serio? Mam się rozumieć że nie można porównywać dwóch różnych implementacji mikroarchitektur bo?
    
    Obie mikroarchitektury mają 3xALU z tym że Intel ma 2 ALU z logiką FP. K10 ma 3x AGU i osobny blok FPU z 3 portami FP. A mimo wszystko Conroe osiąga wyższy IPC. To odnośnie tego że napisałeś że K10 ograniczony jest 3 potokami i niebyłby w stanie wykorzystać dekoder 4-Way.
    
    Intel nie bez powodu stosuje dekoder w konfiguracji 1 złożony a pozostałe proste.
    
    Poza tym AMD jeśli wyłączyłoby 4 dekoder(z pewnych względów) na pewno nie chwaliłoby się tym w materiałach prasowych itd. Na zdjęciach struktury K10 porównując do analizy K8 przez chiparchitect wyraźnie widać że są 4 struktury dekodowania zamiast 3 z K8. Pamiętam że ówcześnie ktążyły plotki że 4 wyłączony dekoder w K10 był wyłącznie do wewnętrznych testów AMD.
    
    
    
    
35. @CD (autor: PCCPU | data: 16/08/24 | godz.: 19:27)
    Symetryczny dekoder jest łatwiejszy w implementacji niż 1+3 ponieważ nie trzeba bardziej złożonej logiki sterowania by decydować które instrukcje mają przechodzić przez 1 a które przez pozostałe.
    
    
36. @PCCPU (autor: Promilus | data: 16/08/24 | godz.: 22:16)
    Bajki piszesz, Chiparchitect nigdzie nie zaznaczył poczwórnego dekodera tylko uznał, że 4 bloczki czegoś koło tego co uznał za dekoder to jest poczwórny microcode flash memory. Rzecz w tym, że to jest takie sranie w banie, bo w K8 są 3 klastry po 8 plasterków + 4 bardziej kwadratowe - i to też jest microcode ROM. W Bulldozer jest podobnie, tam są 4 klastry po 4 plastry i 4 mniejsze. A ciekawe jak by określił drożność dekodera po ROM w Zen2 ;) Gdzie takich klastrów jest co najmniej kilkanaście i nawet trudno wydzielić odrębne struktury. Innymi słowy nie dopowiadaj sobie czegoś czego nie ma. Dekoder jest 3 drożny. I tyle w temacie.
    
    
37. @PCCPU (autor: Promilus | data: 17/08/24 | godz.: 16:18)
    swoją drogą w komentarzu 27 zalinkowałeś slajd który dobitnie pokazuje, że dekoder między K8 a K10 nie zmienił się WCALE. Bo slajd ten - na czerwono - obrazuje czym K10 różni się od K8. W obrębie dekodera nie ma NIC na czerwono. Zupełnie nic! Może zamiast się upierać bez argumentów w końcu albo pokażesz te argumenty, albo przestaniesz wmawiać innym coś czego nie ma.
    
    
38. @Promilus (autor: PCCPU | data: 18/08/24 | godz.: 18:06)
    Zwracam honor. Przejżałem sporo zdjęć struktury rdzenia K10 ale nie mogłem znaleźć wyższej rozdzielczości. Mimo tego wygląda na to że w K10 fizycznie nadal jest 3-Way. Zauważyłem to zanim napisałeś dwa ostatnie komentarze. Dzięki temu znalazłem 4-Way w strukturze Bulldozer i widać to dość wyraźnie.
    
    Co do wyżej zamieszczonych diagramów K10 i Conroe to miałem na celu pokazanie Ci że K10 wcale nie ma mniej jednostek wykonawczych zwłaszcza ALU.
    
    
39. @PCCPU (autor: Promilus | data: 20/08/24 | godz.: 05:30)
    No i git, najważniejsze, że sprawa wyjaśniona i poszkodowanych brak, bo do napierdzielania się sztachetami jeszcze nie doszło :D
    
    A co do conroe - load i store to równie ważne jednostki co alu, nieraz branch był osobną. Pytanie czy są różnice jak one występują u AMD, a jak u intela? No są. Więc DA się porównywać TYLKO pod kątem ilości ALU? No nie. Bo mikroinstrukcje są generowane z x86 zupełnie inne i w zupełnie inny sposób trafiają do potoków wykonawczych.
    
    
40. @Promilus (autor: PCCPU | data: 22/08/24 | godz.: 23:38)
    Całość można porównać, gdyż obie mikroarchitektury generalnie wykonują dokładnie te same instrukcje x86 (poza rozszerzeniami ISA takimi jak SSE, np. 4.1 itp.). Najważniejsza różnica polega na sposobie wykonywania tych instrukcji, ponieważ Conroe ma inną logikę i algorytmy kontrolujące zasoby rdzenia w porównaniu do K10. Ostatecznie jednak można zmierzyć przepustowość każdej części mikroarchitektury rdzenia i skuteczność logiki sterującej.
    
    Jeśli chodzi o potoki to jest to duże uproszczenie z którego skorzystałem. Najważniejsza jest logika sterowania i zawarte w niej algorytmy. Bez odpowiedniej logiki sterującej rdzeniem to nawet i 20 potoków ALU nie pomoże.
    
    
41. EDIT (autor: PCCPU | data: 22/08/24 | godz.: 23:41)
    Całość można porównać, gdyż obie mikroarchitektury generalnie wykonują dokładnie te same instrukcje x86 (poza rozszerzeniami ISA takimi jak SSE, np. 4.1 itp.). Najważniejsza różnica polega na sposobie wykonywania tych instrukcji, ponieważ Conroe ma inną logikę i algorytmy w niej zawarte kontrolujące zasoby rdzenia w porównaniu do K10. Ostatecznie jednak można zmierzyć przepustowość każdej części mikroarchitektury rdzenia i skuteczność logiki sterującej.
    
    Jeśli chodzi o potoki to jest to duże uproszczenie z którego skorzystałem. Najważniejsza jest logika sterowania i zawarte w niej algorytmy. Bez odpowiedniej logiki sterującej rdzeniem to nawet i 20 potoków ALU nie pomoże.
    
    
    
42. @PCCPU (autor: Promilus | data: 24/08/24 | godz.: 14:19)
    Ale ALU nie wykonują rozkazów x86. Wykonują mikroinstrukcje (u intela) i makroinstrukcje (u AMD) które są zupełnie inne :) Więc to co realnie można porównywać to ile instrukcji x86 można naraz (teoretycznie szczytowo) przetwarzać i ile przeciętnie rzeczywiście się da. W tym zakresie Core2 MÓGŁ dekodować teoretycznie 4 instrukcje x86 naraz, a K10 tylko 3. A przecież nie był aż tak gorszy. Core2 ma też instrukcje mikrofuzji, których jak mnie pamięć nie myli K10 nadal nie posiadał. Architektura za dekoderami definiuje jak sprawnie te zdekodowane rozkazy są przetwarzane. W końcu największa zmiana dot. nehalema to mały L0 cache zawierający już zdekodowane instrukcje, a już to robiło robotę, bo nie trzeba ponownie dekodować rozkazów z krótkich pętli - one wykonują się wtedy bez przelatywania ponownie przez cały front end. Pozostałe różnice dotyczyły SMP - integracja kontrolera pamięci w układzie procesora oraz zdecydowanie sprawniejsza komunikacja między rdzeniami. Intelowskie łączenie różnych jednostek na portach (0,1,5) jest bardzo odmienne od rozwiązań AMD gdzie FPU jest wydzielone zupełnie poza struktury związane z rozkazami x86. Intel dzięki takiemu rozwiązaniu mógł zaimplementować AVX2 wykorzystując logikę ALU do rozszerzenia szerokości FPU. AMD musiało albo taktować 128b FPU szybciej, albo zrobić szersze FPU (co stało się w Zen5).
    
    
43. @Promilus (autor: PCCPU | data: 24/08/24 | godz.: 18:55)
    A o czym ja napisałem? :) Na wejściu, czyli instrukcje/dane które pobiera Conroe i K10 są dokładnie takie same(x86). Różnica polega na sposobie przetwarzania i technik użytych w tym celu. Inna logika i algorytmy sterujące zasobami. Na wyjściu rdzeń musi zwrócić dokładnie takie same dane(wyniki) nie zależnie czy to K10, Conroe, LionCove czy Zen5.
    
    Z tego co wiem makroinstrukcja u AMD to 2ops podczas gdy mikroinstrukcja to 1ops.
    
    
44. @Promilus (autor: PCCPU | data: 24/08/24 | godz.: 19:10)
    Poza tym że dekoder AMD dekoduje x86 na MOP czyli 2uOP(operacja arytmetyczna + operacja na pamięci) nie znaczy że w dalszej części potoku logika rdzenia nie dostarcza uOP do ALU. Zarówno Intela jak i AMD jednostki ALU przetwarzają uop.
    
    
45. ETID (autor: PCCPU | data: 24/08/24 | godz.: 19:17)
    Podsumowując: Zarówno Intela jak i AMD rdzenie na wejściu pobierają dokładnie takie same dane x86. Wewnętrznie w jaki sposób rdzeń przetwarza instrukcje x86 zależy od projektu i technik użytch w tym celu. AMD jak i Intel stosują odmienne techniki i sposoby ich przetwarzania ale na wyjści muszą zwrucić dokładnie takie same(kompatybilne)dane/wyniki.
    
    
46. Edit2 (autor: PCCPU | data: 24/08/24 | godz.: 19:34)
    I to że dekodery AMD mają możliwość zdekodowania do MOP(2uOP) nie znaczy że za każdym razem tak się dzieje. Podejrzewam że przez większość czasu dekodery AMD puszczają 1uOP.
    
    Podobnie jak z pierwszy(złożony) dekoder Intela, który ma możliwość dekodowania i szczytowo puszcza 4uop co nie oznacza że dzieje się tak w każdym cyklu dekodowania x86.
    
    
47. Edit (autor: PCCPU | data: 24/08/24 | godz.: 20:23)
    W sumie powinenembył napisać pierwszy złożony potok dekodera.